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IN THE CLAIMS 

This listing of claims will replace all prior versions, and listings, of claims in the 
application. 

Listing of Claims: 



1 1 . (Currently amended) A method for managing access to a resource, the method 

2 comprising the computer-implemented steps of: 

3 sending, from a requestor to a master of the resource, a lock mode request for a 

4 lock mode on the resource; 

5 receiving the resource at the requestor from a holder of the resource, wherein the 

6 holder of the resource is separate and distinct from the master of the 

7 resource , and wherein the holder is a process that currently holds rights to 

8 access the resource by virtue of a lock mode, on the resource, that was 

9 previously granted to the holder by the master of the resource ; and 

10 accessing the resource as if the requestor had been granted the lock mode without 

1 1 waiting to receive an express lock mode grant from the master. 

1 2. (Previously presented) The method of Claim 1, further comprising the computer- 

2 implemented steps of: 

3 detecting that the step of receiving the resource at the requestor has occurred; and 

4 sending a lock assume message, from the requestor to the master, to inform the 

5 master that the requestor has assumed the lock mode relative to the 

6 resource. 

1 3. (Previously presented) A method for managing access to a resource, the method 

2 comprising the computer-implemented steps of: 

3 receiving, at a holder, an inform lock holder message that a requestor needs the 

4 resource, where the holder currently holds the resource and a first lock 

5 mode on the resource; 

6 transferring the resource to the requestor in response to receiving the inform lock 

7 holder message without sending a status message to a master of the 
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8 resource wherein the status message is a down-convert message or a 

9 release lock message; and 

10 updating a lock mode record, maintained by the holder, to indicate that the holder 

1 1 has down-converted from the first lock mode to a second lock mode for 

12 the resource. 

1 4. (Previously presented) The method of Claim 3, further comprising the computer- 

2 implemented step of: 

3 sending an update lock message to the master, wherein the update lock message 

4 indicates the second lock mode for the resource. 

1 5. (Previously presented) The method of Claim 3, further comprising the computer- 

2 implemented steps of: 

3 receiving, at the holder, a message from a sender, wherein the message includes a 

4 third lock mode on the resource; 

5 detecting that the first lock mode and the third lock mode do not match; and 

6 sending a lock status message to the sender, wherein the lock status message 

7 includes the first lock mode. 

1 6. (Previously presented) The method of Claim 3, further comprising the computer- 

2 implemented steps of: 

3 receiving, at the holder, a single batched inform lock holder message that contains 

4 all information necessary to transfer the resource to a plurality of 

5 requestors; and 

6 transferring the resource to the plurality of requestors. 

1 7. (Previously presented) The method of Claim 3, further comprising the computer- 

2 implemented step of: 

3 sending a lock access message from the holder to a master. 

1 8. (Previously presented) A method for managing access to a resource, the method 
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2 comprising the computer-implemented steps of: 

3 receiving, at a master, a request message which indicates that a requestor needs a 

4 particular resource of a plurality of resources, where the master maintains 

5 a plurality of lock mode records corresponding to the plurality of 

6 resources; 

7 sending, from the master to a holder, an inform lock holder message to indicate to 

8 the holder that the requestor needs the particular resource and to identify 

9 the requestor to the holder to allow the holder to send the particular 

10 resource directly to the requestor; 

1 1 receiving a lock access message from the requestor where the lock access message 

12 indicates that the requestor has assumed a lock mode relative to the 

13 particular resource; and 

14 performing an update to a particular lock mode record of the plurality of lock 

15 mode records in response to receiving the lock access message, wherein 

16 the update indicates that the requestor has assumed the lock mode on the 

1 7 particular resource. 

1 9. (Previously presented) The method of Claim 8, wherein the computer- 

2 implemented step of performing an update to a particular lock mode record of the 

3 plurality of lock mode records in response to receiving the plurality of lock mode 

4 records in response to receiving the lock access message is performed prior to 

5 receiving any status message from the holder relating to the particular resource, 

6 and wherein the status message is a down-convert message or a release lock 

7 message. 

1 10. (Previously presented) The method of Claim 8, wherein the computer- 

2 implemented step of performing an update to a particular lock mode record of the 

3 plurality of lock mode records in response to receiving the plurality of lock mode 

4 records in response to receiving the lock access message is performed without 

5 receiving the status message from the holder relating to the particular resource, 

6 and wherein the status message is a down-convert message or a release lock 
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7 message. 

1 11. (Previously presented) The method of Claim 8, further comprising the computer- 

2 implemented steps of: 

3 receiving, at the master, a plurality of request messages which indicate that a 

4 plurality of requestors need the particular resource; and 

5 sending from the master to the holder the inform lock holder message a wherein the 

6 inform lock holder message contains all information from the plurality of 

7 request messages that is necessary for the holder to transfer the particular 

8 resource to the plurality of requestors. 

1 12. (Previously presented) The method of Claim 8, further comprising the computer- 

2 implemented steps of: 

3 receiving, at the master, a message from a sender, wherein the message includes a 

4 second lock mode on the particular resource; 

5 detecting that the lock mode and the second lock mode do not match; and 

6 sending a lock status message to the sender, wherein the lock status message 

7 includes the lock mode. 

1 13. (Previously presented) The method of Claim 8, further comprising the computer- 

2 implemented steps of: 

3 receiving, at the master, a second request message, wherein the request message 

4 and the second request message both contain requests for the resource in 

5 exclusive lock mode; and 

6 queuing the second request message until the master receives the lock access 

7 message from the requestor. 

1 14. (Previously presented) A method for managing access to a resource, the method 

2 comprising the computer-implemented steps of: 

3 receiving, at a master, a request message which indicates that a requestor needs a 

4 particular resource of a plurality of resources, where the master maintains 
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5 a plurality of lock mode records corresponding to the plurality of 

6 resources; 

7 designating one holder out of a plurality of holders wherein the plurality of 

8 holders all have respective lock modes for the particular resource; 

9 sending a plurality of broadcast inform lock holder messages s to the plurality of 

10 holders except for the one holder, indicating that the requestor needs the 

1 1 particular resource; 

12 receiving a plurality of update lock messages from the plurality of holders except 

13 for the one holder, wherein the plurality of update lock messages indicates 

14 the respective lock modes of the plurality of holders; 

15 sending, from the master to the one holder, an inform lock holder message to 

16 indicate to the one holder that the requestor needs the particular resource; 

17 receiving a lock access message from the requestor where the lock access message 

1 8 indicates that the requestor has assumed a lock mode relative to the 

1 9 particular resource; and 

20 performing an update to a particular lock mode record of the plurality of lock 

2 1 mode records in response to receiving the lock access message without the 

22 master receiving a status message from the one holder, wherein the status 

23 message is a down-convert message or a release lock message, and 

24 wherein the update indicates that the requestor has assumed the lock mode 

25 on the particular resource. 

1 15. (Currently amended) A computer system, comprising: 

2 a processor; 

3 a computer-readable medium storing instructions of the computer system which, 

4 when executed by the processor, cause the processor to perform the computer- 

5 implemented steps of: 

6 sending, from a requestor to a master of a resource, a lock mode request for the 

7 lock mode on the resource; 

8 receiving the resource at the requestor from a holder of the resource, wherein the 

9 holder of the resource is separate and distinct from the master of the 
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10 resource , and wherein the holder is a process that currently holds rights to 

11 access the resource by virtue of a lock mode, on the resource, that was 

12 previously granted to the holder by the master of the resource ; and 

13 accessing the resource as if the requestor had been granted the lock mode without 

14 waiting to receive an express lock mode grant from the master. 

1 16. (Previously presented) The computer system of Claim 15, wherein the computer- 

2 implemented steps further comprise the computer-implemented steps of: 

3 detecting that the step of receiving the resource at the requestor has occurred; and 

4 sending a lock assume message from the requestor to the master to inform the 

5 master that the requestor has assumed the lock mode relative to the 

6 resource. 

1 17. (Previously presented) A computer system, comprising: 

2 a processor; 

3 a computer-readable medium, coupled to the processor, containing: 

4 a particular lock mode record of a plurality of lock mode records 

5 corresponding to a lock mode of a particular resource of a plurality 

6 of resources, where a master maintains the plurality of lock mode 

7 records corresponding to the plurality of resources, wherein the 

8 computer-readable medium stores instructions of the computer 

9 system which, when executed by the processor, cause the processor 

10 to perform the computer-implemented steps of: 

1 1 receiving, at the master, a request message which indicates that a 

1 2 requestor needs the particular resource of the plurality of 

1 3 resources, where the master maintains the plurality of lock 

14 mode records corresponding to the plurality of resources; 

1 5 sending, from the master to a holder, an inform lock holder 

1 6 message to indicate to the holder that the requestor needs 

17 the particular resource and to identify the requestor to the 

1 8 holder to allow the holder to send the particular resource 
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1 9 directly to the requestor; 

20 receiving a lock access message from the requestor where the lock 

2 1 access message indicates that the requestor has assumed the 

22 lock mode relative to the particular resource; and 

23 performing an update to the particular lock mode record of the 

24 plurality of lock mode records in response to receiving the 

25 lock access message without receiving a status message, 

26 and 

27 wherein the update indicates that the requestor has assumed the 

28 lock mode on the particular resource. 

1 18. (Previously presented) The computer system of Claim 1 7, wherein the computer- 

2 implemented step of performing an update to a particular lock mode record of the 

3 plurality of lock mode records in response to receiving the lock access message is 

4 performed prior to receiving any status message from the holder relating to the 

5 particular resource, and wherein the status message is a down-convert message or 

6 a release lock message. 

1 19. (Previously presented) The computer system of Claim 17, wherein the computer- 

2 implemented step of performing an update to a particular lock mode record of the 

3 plurality of lock mode records in response to receiving the plurality of lock mode 

4 records in response to receiving the lock access message is performed without 

5 receiving the status message from the holder relating to the particular resource, 

6 and wherein the status messaige is a down-convert message or a release lock 

7 message. 

1 20. (Previously presented) The computer system of Claim 1 7, wherein computer- 

2 implemented steps further comprise the computer-implemented steps of: 

3 receiving, at the master, a plurality of request messages which indicate that a 

4 plurality of requestors need the particular resource; and 

5 sending, from the master to the holder, the inform lock holder message, wherein 
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6 the inform lock holder message contains all information from the plurality 

7 of request messages that is necessary for the holder to transfer the 

8 particular resource to the plurality of requestors. 

1 21. (Previously presented) The computer system of Claim 1 7, wherein the computer- 

2 implemented steps further comprise the computer-implemented steps of: 

3 receiving, at the master, a message from a sender, wherein the message includes a 

4 second lock mode on the particular resource; 

5 detecting that the lock mode and the second lock mode do not match; and 

6 sending a lock status message to the sender^ wherein the lock status message 

7 includes the lock mode. 

1 22. (Previously presented) The computer system of Claim 17, wherein the computer- 

2 implemented steps further comprise the computer- implemented steps of: 

3 receiving, at the master, a second request message wherein the request message 

4 and the second request message both contain requests for the resource in 

5 exclusive lock mode; and 

6 queuing the second request message until the master receives the lock access 

7 message from the requestor. 

1 23. (Previously presented) A computer system, comprising: 

2 a processor; 

3 a computer-readable medium, coupled to the processor, containing: 

4 a particular lock mode record of a plurality of lock mode records 

5 corresponding to a lock mode of a particular resource of a plurality 

6 of resources, where a master maintains the plurality of lock mode 

7 records corresponding to the plurality of resources, wherein the 

8 computer-readable medium stores instructions of the computer 

9 system which, when executed by the processor, cause the processor 

10 to perform the computer-implemented steps of: 

1 1 receiving, at a master, a request message which indicates that a 
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1 2 requestor needs the particular resource of the plurality of 

13 resources, where the master maintains the plurality of lock 

14 mode records corresponding to the plurality of resources; 

1 5 designating one holder out of a plurality of holders wherein the 

16 plurality of holders all have respective lock modes for the 

1 7 particular resource; 

1 8 sending a plurality of broadcast inform lock holder messageSi to 

1 9 the plurality of holders except for the one holder, indicating 

20 that the requestor needs the particular resource; 

2 1 receiving a plurality of update lock messages from the plurality of 

22 holders except for the one holder, wherein the plurality of 

23 update lock messages indicates the respective lock modes 

24 of the plurality of holders; 

25 sending, from the master to the one holder, an inform lock holder 

26 message to indicate to the one holder that the requestor 

27 needs the particular resource; 

28 receiving a lock access message from the requestor where the lock 

29 access message indicates that the requestor has assumed the 

30 lock mode relative to the particular resource; and 

3 1 performing an update to the particular lock mode record of the 

32 plurality of lock mode records in response to receiving the 

33 lock access message without the master receiving a status 

34 message from the one holder, 

35 wherein the status message is a down-convert message or a release 

36 lock message, and 

37 wherein the update indicates that the requestor has assumed the 

38 lock mode on the particular resource. 

1 24. (Previously presented) A computer system, comprising: 

2 a processor; 

3 a computer-readable medium, coupled to the processor, containing: 
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4 a resource and a first lock mode on the resource; and 

5 a lock mode record associated with the resource, wherein the computer- 

6 readable medium stores instructions of the computer system which, 

7 when executed by the processor, cause the processor to perform the 

8 computer-implemented steps of: 

9 receiving, at a holder, an inform lock holder message that a 

10 requestor needs the resource, wherein the holder currently 

1 1 holds the resource and the first lock mode on the resource; 

12 transferring the resource to the requestor in response to receiving 

13 the inform lock holder message without sending a status 

14 message to a master of the resource wherein the status 

1 5 message is a down-convert message or a release lock 

1 6 message; and 

1 7 updating the lock mode record, maintained by the holder, to 

1 8 indicate that the holder has down-converted from the first 

1 9 lock mode to a second lock mode for the resource. 

1 25. (Previously presented) The computer system of Claim 24, wherein the computer- 

2 implemented steps further comprise the computer-implemented step of: 

3 sending an update lock message to the master, wherein the update lock message 

4 indicates the second lock mode for the resource. 

1 26. (Previously presented) The computer system of Claim 24, wherein the computer- 

2 implemented steps further comprise the computer-implemented steps of: 

3 receiving, at the holder, a message from a sender, wherein the message includes a 

4 third lock mode on the resource; 

5 detecting that the first lock mode and the third lock mode do not match; and 

6 sending a lock status message to the sender, wherein the lock status message 

7 includes the first lock mode. 

1 27. (Previously presented) The computer system of Claim 24 wherein the computer- 
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2 implemented steps further comprise the computer-implemented steps of: 

3 receiving, at the holder, a single batched inform lock holder message that contains 

4 all information necessary to transfer the resource to a plurality of 

5 requestors; and 

6 transferring the resource to the plurality of requestors. 

1 28. (Currently amended) A computer-readable medium carrying one or more 

2 sequences of instructions for managing access to a resource, wherein execution of 

3 the one or more sequences of instructions by one or more processors causes the 

4 one or more processors to perform the steps of: 

5 sending, from a requestor to a master of the resource, a lock mode request for a 

6 lock mode on the resource; 

7 receiving the resource at the requestor from a holder of the resource, wherein the 

8 holder of the resource is separate and distinct from the master of the 

9 resource , and wherein the holder is a process that currently holds rights to 

10 access the resource by virtue of a lock mode, on the resource, that was 

1 1 previously granted to the holder by the master of the resource ; and 

12 accessing the resource as if the requestor had been granted the lock mode request 

13 without waiting to receive an express lock mode grant from the master. 

1 29. (Previously presented) The computer-readable medium of Claim 28, wherein 

2 execution of the one or more sequences of instructions by the one or more 

3 processors causes the one or more processors to further perform the steps of: 

4 detecting that the step of receiving the resource at the requestor has occurred; and 

5 sending a lock assume message from the requestor to the master to inform the 

6 master that the requestor has assumed the lock mode relative to the 

7 resource. 

1 30. (Previously presented) A computer-readable medium carrying one or more 

2 sequences of instructions for managing access to a resource, wherein execution of 

3 the one or more sequences of instructions by one or more processors causes the 
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4 one or more processors to perform the steps of: 

5 receiving, at a holder, an inform lock holder message that a requestor needs the 

6 resource, where the holder currently holds the resource and a first lock 

7 mode on the resource; 

8 transferring the resource to the requestor in response to receiving the inform lock 

9 holder message without sending a status message to a master of the 

10 resource wherein the status message is a down-convert message or a 

1 1 release lock message; and 

12 updating a lock mode record, maintained by the holder, to indicate that the holder 

1 3 has down-converted from the first lock mode to a second lock mode for 

14 the resource. 

1 31. (Previously presented) The computer-readable medium of Claim 30, wherein 

2 execution of the one or more sequences of instructions by the one or more 

3 processors causes the one or more processors to further perform the step of: 

4 sending an update lock message to the master, wherein the update lock message 

5 indicates the second lock mode for the resource. 

1 32. (Previously presented) The computer-readable medium of Claim 30, wherein 

2 execution of the one or more sequences of instructions by the one or more 

3 processors causes the one or more processors to further perform the steps of: 

4 receiving, at the holder, a message from a sender, wherein the message includes a 

5 third lock mode on the resource; 

6 detecting that the first lock mode and the third lock mode do not match; and 

7 sending a lock status message to the sender, wherein the lock status message 

8 includes the first lock mode. 

1 33. (Previously presented) The computer-readable medium of Claim 30, wherein 

2 execution of the one or more sequences of instructions by the one or more 

3 processors causes the one or more processors to further perform the steps of: 

4 receiving, at the holder, a single batched inform lock holder message that contains 
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5 all information necessary to transfer the resource to a plurality of 

6 requestors; and 

7 transferring the resource to the plurality of requestors. 

1 34. (Previously presented) The method for Claim 30, wherein execution of the one or 

2 more sequences of instructions by the one or more processors causes the one or 

3 more processors to further perform the step of: 

4 sending a lock access message from the holder to a master. 

1 35 . (Previously presented) A computer-readable medium carrying one or more 

2 sequences of instructions for managing access to a resource, wherein execution of 

3 the one or more sequences of instructions by one or more processors causes the 

4 one or more processors to perform the steps of: 

5 receiving, at a master, a request message which indicates that a requestor needs a 

6 particular resource of a plurality of resources, wherein the master 

7 maintains a plurality of lock mode records corresponding to the plurality 

8 of resources; 

9 sending, from the master to a holder, an inform lock holder message to indicate to 

10 the holder that the requestor needs the particular resource and to identify 

1 1 the requestor to the holder to allow the holder to send the particular 

1 2 resource directly to the requestor; 

1 3 receiving a lock access message from the requestor where the lock access message 

14 indicates that the requestor has assumed a lock mode relative to the 

15 particular resource; and 

16 performing an update to a particular lock mode record of the plurality of lock 

17 mode records in response to receiving the lock access message, wherein 

1 8 the update indicates that the requestor has assumed the lock mode on the 

1 9 particular resource. 

1 36. (Previously presented) The computer-readable medium of Claim 35, wherein the 

2 step of performing an update to a particular lock mode record of the plurality of 
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3 lock mode records in response to receiving the lock access message is performed 

4 prior to receiving any status message from the holder relating to the particular 

5 resource, and wherein the status message is a down-convert 

6 message or a release lock message. 

1 37. (Previously presented) The computer-readable medium of Claim 35, wherein the 

2 step of performing an update to a particular lock mode record of the plurality of 

3 lock mode records in response to receiving the plurality of lock mode records in 

4 response to receiving the lock access message is performed without receiving the 

5 status message from the holder relating to the particular resource, and wherein the 

6 status message is a down-convert message or a release lock message. 

1 38. (Previously presented) The computer-readable medium of Claim 35, wherein 

2 execution of the one or more sequences of instructions by the one or more 

3 processors causes the one or more processors to further perform the steps of: 

4 receiving, at the master, a plurality of request messages which indicate that a 

5 plurality of requestors need the particular resource; and 

6 sending, from the master to the holder, the inform lock holder message, wherein 

7 the inform lock holder message contains all information from the plurality 

8 of request messages that is necessary for the holder to transfer the 

9 particular resource to the plurality of requestors. 

1 39. (Previously presented) The computer-readable medium of Claim 35, wherein 

2 execution of the one or more sequences of instructions by the one or more 

3 processors causes the one or more processors to further perform the steps of: 

4 receiving, at the master, a message from a sender, wherein the message includes a 

5 second lock mode on the particular resource; 

6 detecting that the lock mode and the second lock mode do not match; and 

7 sending a lock status message to the sender, wherein the lock status message 

8 includes the lock mode. 
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1 40. (Previously presented) The computer-readable medium of Claim 35, wherein 

2 execution of the one or more sequences of instructions by the one or more 

3 processors causes the one or more processors to further perform the steps of: 

4 receiving, at the master, a second request message, wherein the request message 

5 and the second request message both contain requests for the resource in 

6 exclusive lock mode; and 

7 queuing the second request message until the master receives the lock access 

8 message from the requestor. 

1 41. (Previously presented) A computer-readable medium carrying one or more 

2 sequences of instructions for managing access to a resource, wherein execution of 

3 the one or more sequences of instructions by one or more processors causes the 

4 one or more processors to perform the steps of: 

5 receiving, at a master, a request message which indicates that a requestor needs a 

6 particular resource of a plurality of resources, where the master maintains 

7 a plurality of lock mode records corresponding to the plurality of 

8 resources; 

9 designating one holder out of a plurality of holders wherein the plurality of 

10 holders all have respective lock modes for the particular resource; 

1 1 sending a plurality of broadcast inform lock holder messages, to the plurality of 

12 holders except for the one holder, indicating that the requestor needs the 

1 3 particular resource; 

14 receiving a plurality of update lock messages from the plurality of holders except 

1 5 for the one holder, 

16 wherein the plurality of update lock messages indicates the respective lock modes 

17 of the plurality of holders; 

18 sending, from the master to the one holder, an inform lock holder message to 

1 9 indicate to the one holder that the requestor needs the particular resource; 

20 receiving a lock access message from the requestor where the lock access message 

21 indicates that the requestor has assumed a lock mode relative to the 

22 particular resource; and 
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23 performing an update to a particular lock mode record of the plurality of lock 

24 mode records in response to receiving the lock access message without the 

25 master receiving a status message from the one holder, 

26 wherein the status message is a down-convert message or a release lock message, 

27 and 

28 wherein the update indicates that the requestor has assumed the lock mode on the 

29 particular resource. 

1 42. (Cancelled). 

1 43. (Cancelled). 
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REMARKS 

The Examiner is thanked for the allowance of Claims 3-14, 17-27, and 30-41 . 

By this amendment, Claims 1,15, and 28 have been amended to expressly recite 
an implicit definition of a term featured therein. Thus, amendments to the claims herein 
are made to improve readability of the claims, without acquiescence of the position of the 
Office Action or prejudice to pursue the previously presented claims in a continuation 
application. No claims have been added or cancelled herein. Hence, Claims 1-41 are 
pending in the application. 

FILED IDS HAS NOT BEEN ACKNOWLEDGED 

The Applicants have filed an Information Disclosure Statement (an "EDS") on 
July 9, 2004. The Applicants have not yet received an initialed form PTO-1449 
acknowledging receipt and consideration of the IDS. Consequently, Applicants 
respectfully request an initialed form PTO-1449 acknowledging receipt and consideration 
of the IDS filed on July 9, 2004. 

SUMMARY OF THE REJECTIONS 

Claims 1-2, 15-16, and 28-29 have been rejected under 35 U.S.C § 102(b) as 
allegedly anticipated by the published patent application WO 91/03024 by Masden et al. 
("Masden"). 

The rejections are respectfully traversed. 
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CLAIMS 1-2, 1516, AND 28-29 ARE PATENTABLE OVER MASDEN 

Each of Claims 1-2, 15-16, and 28-29 are patentable over Masden as each claim 
features subject matter that is not disclosed, taught, or suggested by the cited art. 



Claim 1 is patentable over Masden 
Claim 1 features the elements of: 

"sending, from a requestor to a master of the resource, a lock mode 
request for a lock mode on the resource; 

receiving the resource at the requestor from a holder of the 

resource, wherein the holder of the resource is separate and 
distinct from the master of the resource, and wherein the 
holder is a process that currently holds rights to access the 
resource by virtue of a lock mode, on the resource, that was 
previously granted to the holder by the master of the 
resource ; and 

accessing the resource as if the requestor had been granted the lock 
mode without waiting to receive an express lock mode 
grant from the master." (emphasis added) 

At least the above-underlined element is not disclosed, taught, or suggested by Masden. 

There are significant differences between the approach of Claim 1 and the 
approach of Masden. According to the approach of Claim 1, a requestor sends a lock 
mode request for a lock mode on a resource to a master of the resource. The requestor 
receives the resource from a holder from the resource. The holder of the resource is 
separate and distinct from the master of the resource. The requestor accesses the resource 
as if the requestor had been granted the lock mode without waiting to receive an express 
lock mode grant from the master. Advantageously, the requestor may access the resource 
with greater speed than if the requestor had to wait to receive an express lock mode grant 
from the master of the resource. 
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The Applicants' specification (at page 1, lines 15-16) teaches that a "holder" of a 
data item refers to one or more entities that currently hold the rights to access the data 
item. The specification also teaches that the rights to access a data item are determined 
by virtue of a lock mode granted to the holder by the master of the data item (see, inter 
alia, page 1, line 22 - page 3, line 18). The specification further teaches that the master, 
holder(s), and requester(s) of a data item may be separate processes on a single node, 
processes on separate nodes, or some may be processes on the same node with others on 
separate nodes (See page 1, lines 19-21). Claim 1 is amended herein to expressly recite 
the implicit definition of a holder as used by the Applicants' specification. Specifically, 
Claim 1, as amended, recites the feature of " wherein the holder is a process that currently 
holds rights to access the resource by virtue of a lock mode, on the resource, that was 
previously granted to the holder by the master of the resource." 

The Office Action argues that Masden teaches Claim 1 because: 

the Applicant has indicated in the specification that the holder, master and 
requestor are separate processes, which may be on the same node or 
different nodes (Page 1, Lines 19-21). In Masden' s system the file server 
incorporates separate processes as the holder and master; thus the master 
and the holder are separate and distinct. 

In support of this position, the Office Action argues that a holder, as claimed, is shown by 

mechanism 206 of Masden. Specifically, the Office Action asserts that the feature of 

"receiving the resource at the requestor from a holder of the resource" is shown by 

"(Figure 2, Reference 204 and 206)." 

The element of " receiving the resource at the requestor from a holder of the 

resource, wherein the holder of the resource is separate and distinct from the master of the 

resource" is not disclosed, taught, or suggested by Masden. The Office Action argues that 
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a holder of the resource, as claimed, is taught by mechanism 206 of Masden. However, 
Masden teaches that mechanism 206 "provides storage for system files" (see page 5, lines 
34-35). As such, mechanism 206 cannot be a holder of the resource as claimed, because 
the master of the resource does not and cannot assign, to the mechanism 206, rights to 
access the resource by virtue of a lock mode. In sharp contrast, the function of 
mechanism 206 is to store system files; therefore, while other entities may be assigned 
rights to access a resource stored in the mechanism 206, the system of Masden does not 
assign rights, to mechanism 206, to access a resource . 

As a result, mechanism 206 cannot be read so broadly as to qualify as a holder of 
a resource. Consequently, Masden fails to disclose, teach, or suggest, " receiving the 
resource at the requestor from a holder of the resource, wherein the holder of the resource 
is separate and distinct from the master of the resource" because a mechanism 206 cannot 
be a "holder of the resource" since it cannot be assigned rights to access a resource. 

Additionally, Claim 1 has been amended to recite the feature of " wherein the 
holder is a process that currently holds rights to access the resource by virtue of a lock 
mode, on the resource, that was previously granted to the holder by the master of the 
resource ." For at least the above reasons, Masden does not disclose, teach, or suggest this 
element. Further, mechanism 206 is a storage medium, not a process; thus, mechanism 
206 additional fails to satisfy the claimed feature of this element that the holder "is a 
process." 

Consequently, as at least one element of Claim 1 is not disclosed, shown, or 
suggested by Masden, it is respectfully submitted that Claim 1 is patentable over Masden 
and is in condition for allowance. 
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Claims 2, 15, 16, 28, and 29 are patentable over Mas den 
Claim 1 5 includes limitations similar to Claim 1 , except in the context of a 
system. Claim 28 includes limitations similar to Claim 1, except in the context of a 
computer-readable medium. It is therefore respectfully submitted that Claims 15 and 28 
are each patentable over Masden for at least the reasons given above with respect to 
Claim 1. 

Claims 2, 16, and 29 are dependent claims, each of which depends (directly or 
indirectly) on one of the claims discussed above. Each of Claims 2, 16, and 29 is 
therefore allowable for the reasons given above for the claim on which it depends. In 
addition, each of Claims 2, 16, and 29 introduces one or more additional limitations that 
independently render it patentable. However, due to the fundamental differences already 
identified, to expedite the positive resolution of this case a separate discussion of those 
limitations is not included at this time, although the Applicants reserve the right to further 
point out the differences between the cited art and the novel features recited in the 
dependent claims. 
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CONCLUSION 



For the reasons set forth above, it is respectfully submitted that all of the pending 
claims are now in condition for allowance. Therefore, the issuance of a formal Notice of 
Allowance is believed next in order, and that action is most earnestly solicited. 

The Examiner is respectfully requested to contact the undersigned by telephone if 
it is believed that such contact would further the examination of the present application. 

To the extent necessary, a petition for an extension of time under 37 C.F.R. 
§ 1.136 is hereby made. Please charge any fee shortages or credit any overages to 
Deposit Account No. 50- 1 302. 



Reg. No. 45,620 

2055 Gateway Place, Suite 550 
San Jose, CA 95110-1089 
(408) 414-1080, ext. 225 
Date: July 20, 2005 
Facsimile: (408)414-1076 



Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 
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